home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1104.txt < prev    next >
Text File  |  1994-08-01  |  25KB  |  563 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         H-W. Braun
  8. Request for Comments:  1104                                 Merit/NSFNET
  9.                                                                June 1989
  10.  
  11.  
  12.                      Models of Policy Based Routing
  13.  
  14. 1. Status of this Memo
  15.  
  16.    The purpose of this RFC is to outline a variety of models for policy
  17.    based routing.  The relative benefits of the different approaches are
  18.    reviewed.  Discussions and comments are explicitly encouraged to move
  19.    toward the best policy based routing model that scales well within a
  20.    large internetworking environment.
  21.  
  22.    Distribution of this memo is unlimited.
  23.  
  24. 2. Acknowledgements
  25.  
  26.    Specific thanks go to Yakov Rekhter (IBM Research), Milo Medin
  27.    (NASA), Susan Hares (Merit/NSFNET), Jessica Yu (Merit/NSFNET) and
  28.    Dave Katz (Merit/NSFNET) for extensively contributing to and
  29.    reviewing this document.
  30.  
  31. 3. Overview
  32.  
  33.    To evaluate the methods and models for policy based routing, it is
  34.    necessary to investigate the context into which the model is to be
  35.    used, as there are a variety of different methods to introduce
  36.    policies.  Most frequently the following three models are referenced:
  37.  
  38.        Policy based distribution of routing information
  39.        Policy based packet filtering/forwarding
  40.        Policy based dynamic allocation of network resources (e.g.,
  41.        bandwidth, buffers, etc.)
  42.  
  43.    The relative properties of those methods need to be evaluated to find
  44.    their merits for a specific application.  In some cases, more than
  45.    one method needs to be implemented.
  46.  
  47.    While comparing different models for policy based routing, it is
  48.    important to realize that specific models have been designed to
  49.    satisfy a certain set of requirements.  For different models these
  50.    requirements may or may not overlap.  Even if they overlap, they may
  51.    have a different degree of granularity.  In the first model, the
  52.    requirements can be formulated at the Administrative Domain or
  53.    network number level.  In the second model, the requirements can be
  54.    formulated at the end system level or probably even at the level of
  55.  
  56.  
  57.  
  58. Braun                                                           [Page 1]
  59.  
  60. RFC 1104             Models of Policy Based Routing            June 1989
  61.  
  62.  
  63.    individual users.  In the third model, the requirements need to be
  64.    formulated at both the end system and local router level, as well as
  65.    at the level of Routing Domains and Administrative Domains.
  66.  
  67.    Each of these models looks at the power of policy based routing in a
  68.    different way.  They may be implemented separately or in combination
  69.    with other methods.  The model to describe policy based dynamic
  70.    allocation of network resources is orthogonal to the model of policy
  71.    based distribution of routing information.  However, in an actual
  72.    implementation each of these models may interact.
  73.  
  74.    It is important to realize that the use of a policy based scheme for
  75.    individual network applications requires that the actual effects as
  76.    well as the interaction of multiple methods need to be determined
  77.    ahead of time by policy.
  78.  
  79.    While uncontrolled dynamic routing and allocation of resources may
  80.    have a better real time behavior, the use of policy based routing
  81.    will provide a predictable, stable result based on the desires of the
  82.    administrator.  In a production network, it is imperative to provide
  83.    continuously consistent and acceptable services.
  84.  
  85. 4. Policy based distribution of routing information
  86.  
  87.    Goals:
  88.  
  89.       The goal of this model is to enforce certain flows by means of
  90.       policy based distribution of routing information.  This
  91.       enforcement allows control over who can and who can not use
  92.       specific network resources.
  93.  
  94.       Enforcement is done at the network or Administrative Domain (AD)
  95.       level - macroscopic policies.
  96.  
  97.    Description:
  98.  
  99.       A good example of policy based routing based on the distribution
  100.       of routing information is the NSFNET with its interfaces to mid-
  101.       level networks [1], [2].  At the interface into the NSFNET, the
  102.       routing information is authenticated and controlled by four means:
  103.  
  104.          1. Routing peer authentication based on the source address.
  105.  
  106.          2. Verification of the Administrative Domain identification
  107.             (currently EGP Autonomous System numbers).
  108.  
  109.          3. Verification of Internet network numbers which are
  110.             advertised via the routing peer.
  111.  
  112.  
  113.  
  114. Braun                                                           [Page 2]
  115.  
  116. RFC 1104             Models of Policy Based Routing            June 1989
  117.  
  118.  
  119.          4. Control of metrics via a Routing Policy Data Base for the
  120.             announced Internet network numbers to allow for primary
  121.             paths to the NSFNET as well as for paths of a lesser
  122.             degree.
  123.  
  124.       At the interfaces that pass routing traffic out of the NSFNET, the
  125.       NSS routing code authenticates the router acting as an EGP peer by
  126.       its address as well as the Administrative Domain identification
  127.       (Autonomous System Number).
  128.  
  129.       Outbound announcements of network numbers via the EGP protocol are
  130.       controlled on the basis of Administrative Domains or individual
  131.       network numbers by the NSFNET Routing Policy Data Base.
  132.  
  133.       The NSFNET routing policy implementation has been in place since
  134.       July 1988 and the NSFNET community has significant experience with
  135.       its application.
  136.  
  137.       Another example of policy controlled dissimination of routing
  138.       information is a method proposed for ESNET in [3].
  139.  
  140.    Benefits:
  141.  
  142.       A major merit of the control of routing information flow is that
  143.       it enables the engineering of large wide area networks and allows
  144.       for a more meshed environment than would be possible without tight
  145.       control.  Resource allocation in a non-hostile environment is
  146.       possible by filtering specific network numbers or Administrative
  147.       Domains on a per need basis.  Another important benefit of this
  148.       scheme is that it allows for network policy control with virtually
  149.       no performance degradation, as only the routing packets themselves
  150.       are relevant for policy control.  Routing tables are generated as
  151.       a result of these interactions.  This means that this scheme
  152.       imposes only very little impact on packet switching performance at
  153.       large.
  154.  
  155.    Concerns:
  156.  
  157.       Policy based routing information distribution does not address
  158.       packet based filtering.  An example is the inability to prevent
  159.       malicious attacks by introduced source routed IP packets.  While
  160.       resource allocation is possible, it extends largely to filtering
  161.       on network numbers or whole Administrative Domains, but it would
  162.       not extend to end systems or individual users.
  163.  
  164.    Costs:
  165.  
  166.       Policy based routing in the NSFNET is implemented in a series of
  167.  
  168.  
  169.  
  170. Braun                                                           [Page 3]
  171.  
  172. RFC 1104             Models of Policy Based Routing            June 1989
  173.  
  174.  
  175.       configuration files.  These configuration files are in turn
  176.       generated from a routing information database.  The careful
  177.       creation of this routing information database requires knowledge
  178.       of the Internet at large.  Because the Internet is changing
  179.       constantly, the upkeep of this routing information database is a
  180.       continuous requirement.  However, the effort of collecting and
  181.       maintaining an accurate view of the Internet at large can be
  182.       distributed.
  183.  
  184.       Since policy controlled distribution of routing information allows
  185.       for filtering on the basis of network numbers or Administrative
  186.       Domains, the routing information database only needs to collect
  187.       information for the more than 1300 networks within the Internet
  188.       today.
  189.  
  190. 5. Policy based packet filtering/forwarding
  191.  
  192.    Goals:
  193.  
  194.       The goal of the model of policy based packet filtering/forwarding
  195.       is to allow the enforcement of certain flows of network traffic on
  196.       a per packet basis.  This enforcement allows the network
  197.       administrator to control who can and who can not use specific
  198.       network resources.
  199.  
  200.       Enforcement may be done at the end system or even individual user
  201.       level - microscopic policies.
  202.  
  203.    Description:
  204.  
  205.       An example of packet/flow based policies is outlined in [4].  In a
  206.       generic sense, policy based packet filtering/forwarding allows
  207.       very tight control of the distribution of packet traffic.  An
  208.       implemented example of policy based filtering/forwarding is a
  209.       protection mechanism built into the NSFNET NSS structure, whereby
  210.       the nodes can protect themselves against packets targeted at the
  211.       NSFNET itself by filtering according to IP destination. While this
  212.       feature has so far not been enabled, it is fully implemented and
  213.       can be turned on within a matter of seconds.
  214.  
  215.    Benefits:
  216.  
  217.       The principal merit of this scheme is that it allows the
  218.       enforcement of packet policies and resource allocation down to
  219.       individual end systems and perhaps even individual end users.  It
  220.       does not address a sane distribution of routing information.  If
  221.       policies are contained in the packets themselves it could identify
  222.       users, resulting in the ability of users to move between
  223.  
  224.  
  225.  
  226. Braun                                                           [Page 4]
  227.  
  228. RFC 1104             Models of Policy Based Routing            June 1989
  229.  
  230.  
  231.       locations.
  232.  
  233.    Concerns:
  234.  
  235.       The major concern would be the potentially significant impact on
  236.       the performance of the routers, as, at least for tight policy
  237.       enforcements, each packet to be forwarded would need to be
  238.       verified against a policy data base.  This limitation makes the
  239.       application of this scheme questionable using current Internet
  240.       technology, but it may be very applicable to circuit switched
  241.       environments (with source-routed IP packets being similar to a
  242.       circuit switched environment).  Another difficulty could be the
  243.       sheer number of potential policies to be enforced, which could
  244.       result in a very high administrative effort.  This could result
  245.       from the creation of policies at the per-user level.  Furthermore,
  246.       the overhead of carrying policy information in potentially every
  247.       packet could result in additional burdens on resource
  248.       availabilities.  This again is more applicable to connection-
  249.       oriented networks, such as public data networks, where the policy
  250.       would only need to be verified at the call setup time.  It is an
  251.       open question how well packet based policies will scale in a large
  252.       and non homogeneous Internet environment, where policies may be
  253.       created by all of the participants.  These creations of policy
  254.       types of services may have to be doable in real time.
  255.  
  256.       Scaling may require hierarchy.  Hierarchy may conflict with
  257.       arbitrary Type of Service (TOS) routing, which is one of the
  258.       benefits of this model.
  259.  
  260.    Costs of implementation:
  261.  
  262.       A large scale implemention of packet based policy routing would
  263.       require a routing information base that would contain information
  264.       down to the end system level and possibly end users.  If one would
  265.       assume that for each of the 1300 networks there is an average of
  266.       200 end systems, this would result in over 260000 end systems
  267.       Internet wide.  Each end system in turn could further contribute
  268.       some information on the type of traffic desired, including types
  269.       of service (issues like agency network selection), potentially on
  270.       a per-user basis.  The effort for the routing policy data base
  271.       could be immense, in particular if there is a scaling requirement
  272.       towards a variety of policies for backbones, mid-level networks,
  273.       campus networks, subnets, hosts, and users.  The administration of
  274.       this "packet routing" database could be distributed.  However,
  275.       with a fully distributed database of this size several consistency
  276.       checks would have to be built into the system.
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Braun                                                           [Page 5]
  283.  
  284. RFC 1104             Models of Policy Based Routing            June 1989
  285.  
  286.  
  287. 6. Policy based dynamic allocation of network resources (e.g.,
  288.       bandwidth, buffers, etc.).
  289.  
  290.    Goals:
  291.  
  292.       Flexible and economical allocation of network resources based on
  293.       current needs and certain policies.  Policies may be formulated at
  294.       the network or Administrative Domain (AD) levels.  It is also
  295.       possible to formulate policies which will regulate resource
  296.       allocation for different types of traffic (e.g., Telnet, FTP,
  297.       precedence indicators, network control traffic).
  298.  
  299.       Enforcement of policy based allocation of network resources might
  300.       be implemented within the following parts of the network:
  301.  
  302.           routers for networks and Administrative Domain (AD) levels
  303.           circuit switches for networks
  304.           end systems establishing network connections
  305.  
  306.    Description:
  307.  
  308.       Policy based allocation of bandwidth could allow the modulation of
  309.       the circuits of the networking infrastructure according to real
  310.       time needs.  Assuming that available resources are limited towards
  311.       an upper bound, the allocation of bandwidth would need to be
  312.       controlled by policy.  One example might be a single end system
  313.       that may or may not be allowed to, perhaps even automatically,
  314.       take resources away from other end systems or users.  An example
  315.       of dynamic bandwidth allocation is the currently implemented
  316.       circuit switched IDNX component of the NSFNET, as well as the MCI
  317.       Digital Reconfiguration Service (DRS) which is planned for the
  318.       NSFNET later this year.
  319.  
  320.       Another model for resource allocation occurs at the packet level,
  321.       where the allocation is controlled by multiple packet queues.
  322.       This could allow for precedence queuing, with preferences based on
  323.       some type of service and preferred forwarding of recognized
  324.       critical data, such as network monitoring, control and routing.
  325.       An example can be found in the NSFNET, where the NSFNET nodes
  326.       prefer traffic affiliated with the NSFNET backbone network number
  327.       over all other traffic, to allow for predictable passing of
  328.       routing information as well as effective network monitoring and
  329.       control.  At the other end of the spectrum, an implementation
  330.       could also allow for queues of most deferrable traffic (such as
  331.       large background file transfers).
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Braun                                                           [Page 6]
  339.  
  340. RFC 1104             Models of Policy Based Routing            June 1989
  341.  
  342.  
  343.    Benefits:
  344.  
  345.       Dynamic allocation of bandwidth could allow for a truly flexible
  346.       environment where the networking infrastructure could create
  347.       bandwidth on a per need basis.  This could result in significant
  348.       cost reductions during times when little bandwidth is needed.
  349.       This method could potentially accommodate real time transient high
  350.       bandwidth requirements, potentially by reducing the bandwidth
  351.       available to other parts of the infrastructure.  A positive aspect
  352.       is that the bandwidth allocation could be protocol independent,
  353.       with no impact on routing protocols or packet forwarding
  354.       performance.
  355.  
  356.       Policy based allocation of bandwidth can provide a predictable
  357.       dynamic environment.  The rules about allocation of bandwidth at
  358.       the circuit level or at the packet level need to be determined by
  359.       a consistent and predictable policy, so that other networks or
  360.       Administrative Domains can tune their allocation of networking
  361.       resources at the same time.
  362.  
  363.    Concerns:
  364.  
  365.       The policies involved in making dynamic bandwidth allocation in a
  366.       largely packet switching environment possible are still in the
  367.       development phase.  Even the technical implications of
  368.       infrastructure reconfiguration in result of events happening on a
  369.       higher level still requires additional research.
  370.  
  371.       A policy based allocation of bandwidth could tune the network to
  372.       good performance, but could cause networks located in other
  373.       Administrative Domains to pass traffic poorly.  It is important
  374.       that network resource policy information for a network be
  375.       discussed within the context of its Administrative Domain.
  376.       Administrative Domains need to discuss their network resource
  377.       allocation policies with other Administrative Domains.
  378.  
  379.       The technical problem of sharing network resource policy
  380.       information could be solved by a making a "network resource policy
  381.       information" database available to all administrators of networks
  382.       and Administrative Domains.  However, the political problems
  383.       involved in creating a network resource policy with impact on
  384.       multiple Administrative Domains does still require additional
  385.       study.
  386.  
  387. 7. Discussion
  388.  
  389.    Both the first and the second model of policy based routing are
  390.    similar in the sense that their goal is to enforce certain flows.
  391.  
  392.  
  393.  
  394. Braun                                                           [Page 7]
  395.  
  396. RFC 1104             Models of Policy Based Routing            June 1989
  397.  
  398.  
  399.    This enforcement allows the control of access to scarce network
  400.    resources (if the resource is not scarce, there is no performance
  401.    reason to control access to it).  The major difference is the level
  402.    of enforcement: macroscopic level versus microscopic level control.
  403.  
  404.    Associated with the enforcement for a certain network resource is the
  405.    cost.  If this cost is higher than the cost required to make a
  406.    particular resource less scarce, then the feasibility of enforcement
  407.    may be questionable.
  408.  
  409.    If portions of the Internet find that microscopic enforcement of
  410.    policy is necessary, then this will need to be implementable without
  411.    significant performance degradation to the networking environment at
  412.    large.  Local policies within specific Routing Domains or
  413.    Administrative Domains should not affect global Internet traffic or
  414.    routing.  Policies within Administrative Domains which act as traffic
  415.    transit systems (such as the NSFNET) should not be affected by
  416.    policies a single network imposes for its local benefit.
  417.  
  418.    Some models of policy routing are trying to deal with cases where
  419.    network resources require rather complex usage policies.  One of
  420.    scenarios in [4] is one in which a specific agency may have some
  421.    network resource (in the example it is a link) which is sometimes
  422.    underutilized.  The goal is to sell this resource to other agencies
  423.    during the underutilization period to recover expenses.  This
  424.    situation is equivalent to the problem of finding optimum routes,
  425.    with respect to a certain TOS, in the presence of network resources
  426.    (e.g., links) with variable characteristics.  Any proposed solution
  427.    to this problem should address such issues as network and route
  428.    stability.  More feasibility study is necessary for the whole
  429.    approach where links used for global communication are also subject
  430.    to arbitrary local policies.  An alternative approach would be to
  431.    reconfigure the network topology so that underutilized links will be
  432.    dropped and possibly returned to the phone company.  This is
  433.    comparable to what the NSFNET is planning on doing with the MCI
  434.    Digital Reconfiguration Service (DRS).  A DRS model may appear
  435.    cleaner and more easy to implement than a complicated model like the
  436.    one outlined in [4].
  437.  
  438.    The models for policy based routing emphasize that careful
  439.    engineering of the Internet needs to decided upon the profile of
  440.    traffic during normal times, outage periods, and peak loads.  This
  441.    type of engineering is not a new requirement.  However, there could
  442.    potentially be a significant benefit in deciding these policies ahead
  443.    of time and using policy based routing to implement specific routing
  444.    policies.
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Braun                                                           [Page 8]
  451.  
  452. RFC 1104             Models of Policy Based Routing            June 1989
  453.  
  454.  
  455. 8. Accounting vs. Policy Based Routing
  456.  
  457.    Quite often Accounting and Policy Based Routing are discussed
  458.    together.  While the application of both Accounting and Policy Based
  459.    Routing is to control access to scarce network resources, these are
  460.    separate (but related) issues.
  461.  
  462.    The chief difference between Accounting and Policy Based Routing is
  463.    that Accounting combines history information with policy information
  464.    to track network usage for various purposes.  Accounting information
  465.    may in turn drive policy mechanisms (for instance, one could imagine
  466.    a policy limiting a certain organization to a fixed aggregate
  467.    percentage of dynamically shared bandwidth).  Conversely, policy
  468.    information may affect accounting issues.  Network accounting
  469.    typically involves route information (at any level from AD to end
  470.    system) and volume information (packet, octet counts).
  471.  
  472.    Accounting may be implemented in conjunction with any of the policy
  473.    models mentioned above.  Similar to the microscopic versus
  474.    macroscopic policies, accounting may be classified into different
  475.    levels.  One may collect accounting data at the AD level, network
  476.    level, host level, or even at the individual user level.  However,
  477.    since accounting may be organized hierarchically, microscopic
  478.    accounting may be supported at the network or host level, while
  479.    macroscopic accounting may be supported at the network or AD level.
  480.    An example might be the amount of traffic passed at the interface
  481.    between the NSFNET and a mid-level network or between a mid-level
  482.    network and a campus.  Furthermore, the NSFNET has facilities
  483.    implemented to allow for accounting of traffic trends from individual
  484.    network numbers as well as application-specific information.
  485.  
  486.    Full-blown accounting schemes suffer the same types of concerns
  487.    previously discussed, with the added complication of potentially
  488.    large amounts of additional data gathered that must be reliably
  489.    retrieved.  As pointed out in [4], policy issues may impact the way
  490.    accounting data is collected (one administration billing for packets
  491.    that were then dropped in the network of another administration).
  492.    Microscopic accounting may not scale well in a large internet.
  493.  
  494.    Furthermore, from the standpoint of billing, it is not clear that the
  495.    services provided at the network layer map well to the sorts of
  496.    services that network consumers are willing to pay for.  In the
  497.    telephone network (as well as public data networks), users pay for
  498.    end-to-end service and expect good quality service in terms of error
  499.    rate and delay (and may be unwilling to pay for service that is
  500.    viewed as unacceptable).  In an internetworking environment, the
  501.    heterogeneous administrative environment combined with the lack of
  502.    end-to-end control may make this approach infeasible.
  503.  
  504.  
  505.  
  506. Braun                                                           [Page 9]
  507.  
  508. RFC 1104             Models of Policy Based Routing            June 1989
  509.  
  510.  
  511.    Lightweight approaches to accounting can be used (with less impact)
  512.    when specific, limited goals are set.  One suggested approach
  513.    involves monitoring traffic patterns.  If a pattern of abuse (e.g.,
  514.    unauthorized use) develops, an accounting system could track this and
  515.    allow corrective action to be taken, by changing routing policy or
  516.    imposing access control (blocking hosts or nets).  Note that this is
  517.    much less intrusive into the packet forwarding aspects of the
  518.    routers, but requires distribution of a policy database that the
  519.    accounting system can use to reduce the raw information.  Because
  520.    this approach is statistical in nature, it may be slow to react.
  521.  
  522. 9. References
  523.  
  524.    [1] Rekhter, Y., "EGP and Policy Based Routing in the New NSFNET
  525.        Backbone", RFC 1092, IBM Research, February 1989.
  526.  
  527.    [2] Braun, H-W., "The NSFNET Routing Architecture", RFC 1093,
  528.        Merit/NSFNET Project, February 1989.
  529.  
  530.    [3] Collins, M., and R. Nitzan, "ESNET Routing", DRAFT Version 1.0,
  531.        LLNL, May 1989.
  532.  
  533.    [4] Clark, D., "Policy Routing in Internet Protocols", RFC 1102,
  534.        M.I.T. Laboratory for Computer Science, May 1989.
  535.  
  536. Author's Address
  537.  
  538.    Hans-Werner Braun
  539.    Merit Computer Network
  540.    University of Michigan
  541.    1075 Beal Avenue
  542.    Ann Arbor, Michigan 48109
  543.  
  544.    Telephone:      313 763-4897
  545.    Fax:            313 747-3745
  546.    EMail:          hwb@merit.edu
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Braun                                                          [Page 10]
  563.